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ABSTRACT 

At  the  10th  DSM  Conference,  a  team  of  ship  designers  working  to  document  the  naval  ship  design 
process  was  introduced  to  DSM  methods.  The  design  of  a  naval  surface  combatant  ship  is  an  extreme 
example  of  complexity  management.  DSM  was  applied  to  attempt  to  capture  of  expertise  from  the 
technical  community,  through  a  series  of  workshops.  A  custom-built,  integrated  database  approach 
was  planned  to  document  the  results.  Progress  was  reported  at  the  11th  DSM  Conference. 
Subsequently  our  team  discovered  COTS  software  (Plexus)  that  not  only  served  the  database  function 
and  provided  multiple  views  of  process  data,  but  also  provided  a  dynamic  modeling/viewing  user 
interface  that  proved  more  intuitive  to  ship  design  practitioners.  This  paper  describes  our  progress, 
including  the  workshop  process,  framing  principles  (semantic  rules  and  conventions)  that  proved 
helpful,  our  use  of  Plexus,  the  model  we  have  created,  and  our  intended  applications  for  that  model. 
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1  INTRODUCTION 

This  paper  is  to  update  the  DSM  Community  with  regard  to  progress  on  the  US  Navy’s  ship  design 
process  modeling  efforts  since  the  11th  DSM  Conference.  The  background  of  the  Navy’s  ship  design 
process  modeling  efforts  will  be  reviewed,  with  references  to  prior  DSM  presentations  and  other 
recent  publications.  This  includes  the  description  of  six  Ship  Design  Process  Workshops  that  have 
been  conducted  and  the  challenges  of  capturing  and  understanding  knowledge  this  domain.  Initially, 
our  effort  embarked  on  building  a  custom  database,  to  store  this  knowledge,  but  eventually  we  found 
another  solution,  via  commercial-off-the-shelf  software  which  will  be  described  here.  Use  of  this 
software  has  allowed  us  to  formulate  a  generic  process  model  of  value  for  four  distinct  applications. 
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2  BACKGROUND 

Our  efforts  began  with  the  need  for  evaluation  of  the  software  tools  and  processes  used  in  ship  design, 
and  a  need  to  understand  the  return  on  investments  in  these  tools,  to  prioritize  investments  in  them  (the 
key  objective  of  the  Design  Tools  Roadmap  Project,  reported  in  our  paper  at  DSM’09  [1]).  Quickly  it 
was  discovered  that  this  need  could  not  be  satisfied  without  a  design  process  model  to  provide  context. 
Simply  stated,  there  was  little  formal  documentation  of  Navy  knowledge  of  the  ship  design  process 
(and  certainly  none  in  a  format  that  would  permit  quantitative  analysis  of  alternative  processes),  and 
therefore  the  value  of  tools  within  this  process  simply  could  not  be  assessed.  Note  that  our  purpose 
here  is  distinct  from  systems  engineering,  integration  and  validation  processes,  requirements  definition 
or  architectural  design.  The  goal  is  to  capture  and  understand  poorly  documented  existing  processes  in 
the  first  instance,  not  to  engineer  new  processes. 

To  face  this  challenge,  our  team  drew  on  the  expertise  from  the  Navy  Technical  Warrant  Holder 
community  in  order  to  build  the  model,  taking  advantage  of  existing  Design  Process  Workshops, 
sponsored  by  NAVSEA,  the  Office  of  Naval  Research  (ONR)  and  the  CREATE  Program  of  the  Office 
of  the  Secretary  of  Defence  (OSD).  The  Workshops  engaged  a  broad  spectrum  of  the  ship  design 
community.  Among  the  Workshop  attendees  were  experts  in  Machinery  Design,  Integrated  Topside 
Design,  and  Mission  Systems. 

Having  a  way  to  extract  a  high-quality  process  model  description  from  this  community  of  seasoned 
experts  without  existing  documentation  presented  two  main  challenges 

•  There  was  a  need  to  carefully  store  the  process  knowledge  that  we  captured 

•  There  was  a  need  for  a  productive,  well-regulated  process  by  which  the  knowledge  would  be 
captured. 

Initially,  we  began  addressing  the  first  challenge  (how  to  store  the  model)  by  designing  a  database  in 
which  to  store  dependency  knowledge.  However,  we  discovered  a  commercial  off  the  shelf  tool 
(Plexus,  discussed  below),  which  provided  a  more  than  adequate  data  model,  stored  in  sophisticated 
database,  accessible  through  collaborative,  real-time  networked  clients. 

To  address  the  second  challenge  (a  methodology  for  capturing  the  knowledge),  we  initially  considered 
using  the  DSM  itself  as  a  knowledge  capture  too.  However,  while  DSM  is  a  compact  presentation  of 
the  dependencies  between  tasks  in  a  process,  and  affords  analysis  and  manipulation  opportunities  once 
the  knowledge  is  captured,  “filling  in”  DSMs  (for  instance,  in  Excel  spreadsheets  and  similar  tools) 
was  not  found  to  be  an  intuitive  process  for  most  ship  design  practitioners.  Some  studies  have  been 
conducted  in  the  relative  merits  of  users  attempting  to  understand  connectivity  models  like  DSMs  in 
matrices  versus  node-link  representations  (see  [2]  and  its  references),  and  these  studies  indicate  some 
preferences  for  each  representation  in  certain  tasks.  However,  the  process  of  knowledge  capture,  from 
multiple  real-world  experts,  in  workshop  settings,  using  sophisticated,  interactive  software  tools  for 
matrix  and  network  creation,  manipulation,  and  visualization,  is  a  relatively  unexamined  topic. 

In  our  real-world  experience  of  this  sort,  we  found  a  productive  means  of  capturing  knowledge  via 
Plexus,  a  commercial  off  the  shelf  tool  that  affords  collaborative  construction  of  boxes-and-arrows 
diagrams,  that  can  then  be  visualizes  as  DSMs,  and  then  subjected  to  several  types  of  analysis, 
including  cycle  identification,  partitioning,  tearing,  automatic  optimized  scheduling,  critical  path,  and 
stochastic  analysis.  Plexus  was  found  to  be  a  versatile  tool  and  powerful  methodology  with 
outstanding  ability  to  elicit  and  represent  complex  networks  of  activities  and  dependencies  with 
alternative  or  cyclic  logic.  PLEXUS  supports  activity  grouping  in  multiple  hierarchies  and 
significantly  facilitates  sequencing,  scheduling  and  other  trade-off  analysis  for  multiple  objectives. 

The  construction  of  our  process  model  in  Plexus  was  driven  by  a  “product  model”  approach  to  process 
model  development.  That  is,  the  elements  of  the  ship  itself,  divided  into  systems,  framed  our 
methodology  of  knowledge  capture.  Our  product  model  approach  provides  the  same  information  in 
different  ways  to  suit  the  user;  this  builds  on  the  classic  educational  theory  of  multiple  intelligences 
and  is  a  powerful  aspect  of  our  current  approach. 


3  FRAMING  PRINCIPLES  FOR  THE  MODEL 

The  complexity  of  the  ship  design  process  makes  development  of  a  ship  design  process  model 
challenging.  It  quickly  becomes  apparent  that  the  experts  from  which  we  are  capturing  knowledge 


Plexus  Planning  Limited  2011 


bring  a  localized  frame  of  reference  (if  they  are  subject  matter  experts)  or  a  particularized  frame  of 
reference  (if  they  have  been  involved  in  design  integration  for  a  particular  ship  design  in  the  past). 
They  often  use  different  terms  to  describe  the  same  thing  and/or  the  same  term  to  describe  different 
things.  It  is  easy  to  end  up  with  a  stack  of  “expert  views”  in  English  that  are  impossible  to 
comprehend  or  to  collate  into  a  common  model  that  can  be  understood.  Therefore,  it  is  necessary  to 
have  a  model  framework  that  is  robust  enough  to  receive  the  knowledge  captured  from  these  diverse 
perspectives,  and  a  pre-arranged  method  to  collate  their  answers  into  a  model  which  can  be 
manipulated  and  analyzed  to  yield  answers  to  the  fundamental  questions.  An  important  aspect  of  this 
framework  is  the  realization  that,  during  design,  there  are  two  major  vectors  of  activity  -  Physical 
Integration  and  Requirements  Satisfaction: 

•  Physical  Integration  is  achieved  by  making  sure  all  the  definition  products  are  consistent 
(e.g.,  the  general  arrangement  aligns  with  the  hull  form,  the  systems  support  the  arrangement 
of  spaces  and  components,  etc).  The  emphasis  is  on  definition  activities  and  definition-to- 
definition  transactions.  The  quantity  of  data  values  in  these  transactions  is  very  large. 

•  Requirement  Satisfaction  is  achieved  by  evaluation  activities  to  generate  cost,  performance, 
schedule  and  risk  estimates  that  are  compared  with  requirements.  Some  evaluation  activities 
require  inputs  from  multiple  definition  activities.  Other  evaluation  activities  require  input 
from  only  a  single  definition  activity.  Some  evaluation  activities  require  inputs  from  other 
evaluation  activities,  but  the  quantity  of  data  value  in  these  transactions  is  small.  The 
emphasis  is  on  evaluation  activities  and  definition-to-evaluation  transactions,  where  the 
quantity  of  data  values  to  be  transferred  is  very  large. 

Early  in  the  preliminary  phase,  the  design  team  is  willing  to  be  fast  and  loose  regarding  the  Physical 
Integration  vector  as  many  concepts  are  tried  and  discarded.  Near  the  end  of  the  preliminary  phase 
and  certainly  in  the  contract  phase,  there  is  more  emphasis  on  simultaneous  satisfaction  of  the  Physical 
Integration  and  Requirements  Satisfaction  vectors.  In  detail  and  transition  design  phases,  emphasis  is 
mostly  on  Physical  Integration  at  a  high  level  of  detail.  Total-ship  Requirement  Satisfaction  is 
presumed  or  occasionally  checked.  Detail  Requirement  Satisfaction  (pipe  flow  rate,  etc)  is  the 
emphasis  of  evaluation  activities. 

This  “two  vector”  frame  provided  much  of  the  insight  into  modeling  principles  that  we  emphasized  in 
our  workshops,  and  used  as  controls  on  the  construction  of  the  model.  These  principles  were  focused 
on  discipline  in  the  model  semantics,  and  using  a  regulated  vocabulary.  In  our  boxes-and-arrows 
modeling  exercise,  we  emphasized  that  boxes  are  verb  phrases :  activities  that  are  done  to  components 
of  the  product  model.  Arrows  are  those  artifacts.  Plexus  includes  the  ability  to  add  names  and 
descriptions  to  both  boxes  (DSM  rows/columns),  as  well  as  arrows  (dependency  marks  in  a  DSM), 
have  names  and  descriptions.  Given  this,  our  regulated  vocabulary  consisted  of: 

Verbs:  in  constructing  the  verb  phrases  that  name  activities  (boxes,  or  DSM  rows),  we  wanted 
consistency  of  meaning,  and  a  small  set  of  possible  verbs,  with  clear  definitions,  to  develop  a  model 
with  consistent  semantics.  Using  the  “two  vector”  frame  discussed  above,  and  after  some  iteration,  the 
following  set  of  four  verbs  were  decided  upon,  and  used  across  all  the  multi-disciplinary  elements  of 
the  model,  to  good  effect: 

•  Review/Set:  considering  requirements  and  selecting  margins  and  approach 

•  Define 

•  Assess:  considering  and  evaluating  results 

•  Report  or  Circulate 

Levels  of  Detail  (Adjectives):  The  ship  design  process  is  characterized  by  progressive  development 
of  definition  detail  over  the  course  of  several  years.  To  represent  this  consistently,  our  team  developed 
a  “shorthand”  to  allow  quick  but  explicit  reference  to  the  level  of  definition  resulting  from  any 
particular  “definition”  activity.  This  is  also  useful  for  quickly  characterizing  the  extent  of  definition 
input  information  necessary  before  certain  applications  can  be  executed.  Thus,  we  adopted  a  careful 
vocabulary  on  levels  of  detail.  The  vocabulary  varied  across  three  levels  of  ship  design  (Shape, 
Structure,  and  Systems),  and  in  each  provided  appropriate  levels  of  detail,  extracted  from  design 
experience  (e.g.,  Parametric,  3/2. 5D  Sufaces/Arrangements/Reservations,  Manufacturing  Detail, 
Maintenance  Detail,  etc.).  Complete  discussion  is  not  included  here  for  the  sake  of  brevity. 

Nouns:  the  activities  of  our  model  operate  on  parts  of  the  ultimate  product  of  Ship  Design.  It  is 
important  to  note  that  not  only  the  boxes  of  our  model  (activities)  have  names  and  descriptions,  but  so 
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do  the  arrows.  Moreover,  these  parts  and  information  artifacts  are  organized  in  a  product/system 
focused  Work  Breakdown  Structure  (WBS).  This  not  only  helps  organize  the  work  of  knowledge 
capture  (such  that  particular  groups  can  work  separately  on  particular  aspects  of  the  model)  it  also 
provides  a  means  of  collapsing  and  focusing  attention  on  parts  of  the  model  for  analysis  and 
understanding.  A  collapsed  version  of  the  Preliminary  Design  Portion  of  the  model,  showing  the  high- 
level  WBS  elements  that  were  used  to  form  collaborative  groups  for  knowledge  capture,  is  shown  in 
Figure  1. 


/ 


Propulsion/  Power/  Machinery 

Figure  1:  The  Preliminary  Design  portion  of  the  Ship  Design  Process  Model,  showing  the  high- 
level  WBS  elements  used  to  organize  the  model  and  the  knowledge  capture  process.  The 
boxes  are  WBS  elements  “collapsed”  in  Plexus,  with  the  thickness  of  connecting  arrows 
indicated  the  number  of  connections  between  activities  within  those  boxes. 

Resources  (More  Nouns):  The  model  includes  not  only  Activities  and  their  products  (at  various 
levels  of  detail),  all  organized  in  a  WBS,  but  it  includes  the  specifications  of  the  time  and  Resources 
required  to  perform  those  activities.  Thus,  we  also  created  a  standard  lexicon  of  resources,  including: 
The  regulated  vocabulary  provided  a  frame  for  knowledge  capture  in  our  workshops,  which  were 
broken  down  into  3-5  groups  based  on  the  highest  level  of  our  WBS.  These  groups  worked  separately, 
but  simultaneously,  on  a  common  database  that  captured  the  overall  model,  through  a  networked  set  of 
5-10  Plexus  clients.  Each  group  consisted  of  around  20  participants.  Plexus  facilitated  easy  import  (via 
comma  separated  value  files)  of  knowledge  we  had  captured  in  our  workshops  before  we  began  using 
the  tool,  and  some  of  this  knowledge  “seeded”  further  model  developing  in  the  workshops. 

A  collapsed  version  of  the  model,  along  with  the  expansion  to  show  all  the  connectivity,  is  shown  in 
Figure  2.  While  this  static  figure  may  be  difficult  to  read.  Plexus  allows  for  sophisticated  interactive 
zooming,  panning,  collapsing,  expanding,  focusing,  and  path  following  that  facilitate  a  user’ s  ability  to 
create,  visualize,  organize,  and  analyze  models  of  this  sort. 


Figure  2:  The  Ship  Design  Process  Model,  in  collapsed  and  expanded  forms. 


4  INTENDED  APPLICATIONS 

Since  the  inception  of  our  project,  we  have  identified  four  main  applications  of  our  ship  design  process 
model: 
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•  Identifying  specific  gaps  and  weaknesses  in  our  ship  design  capability,  particularly  with  respect 

to  design  tools. 

•  Providing  a  means  of  estimating  the  value  (ROI)  of  specific  design  tool  (activity  improvement) 

and  interoperability  (transaction  improvement)  investments. 

•  Providing  a  flexible  tool  for  particular  ship  design  project  planning  that  will  facilitate 

identification  of  critical  paths  and  optimum  sequencing  of  engineering  efforts.  This  could  be 
particularly  valuable  for  ships  with  mission  requirements,  configurations,  or  technological 
challenges  that  are  different  from  traditional  warships. 

•  Providing  a  core  reference  and  directory  for  Navy  ship  design  process  documentation  to  serve  as 

a  training  aide  for  next-generation  ship  designers. 

We  intend  to  build  a  center  of  excellence  or  competency  that  can  become  proficient  with  the  tools, 
build  a  reference  library,  maintain  configuration  control,  and  be  available  to  assist  projects  as  needed. 
The  objective  is  to  make  the  service  valuable  and  desired  and  respond  to  the  "pull”  of  the  ship  design 
manager  community,  rather  than  dictate  that  the  model  be  used.  We  are  nearing  the  point  of  using  the 
model  in  several  “real  world”  surface  combatant  design  projects. 

In  support  of  these  objects,  Plexus  offers  capabilities  that  our  team  particularly  value:  its  versatility  as 
a  tool,  its  powerful  methodology,  and  its  outstanding  ability  to  elicit  and  represent  complex  networks 
of  activities  and  dependencies  with  alternative  or  cyclic  logic.  Plexus  supports  activity  grouping  in 
multiple  hierarchies  and  significantly  facilitates  sequencing,  scheduling  and  other  trade-off  analyses 
for  multiple  objectives.  Two  particular  capabilities  are  worth  particularly  noting: 

4.1  Focusing,  Filtering,  and  Multi-Domain  Modeling 

To  accomplish  many  of  the  goals  we  have  for  the  model,  we  need  to  be  able  to  examine  and  analyze 
the  details  we  have,  and  be  able  to  expand  that  detail  as  necessary.  We  also  need  to  add  detail  in 
multiple  domains:  while  WBS  provides  an  excellent  domain  for  a  product  driven  process  modeling 
procedure,  we  also  need  to  tie  activities  to  location,  organizational  responsibilities,  etc.  We  also  need 
to  examine  the  project  by  filtering  through  these  multiple  domains:  asking  questions  like  “what  sorts 
of  work  on  the  hull  are  being  conducted  by  a  given  organization  in  a  given  location?”  These  filters 
need  to  be  visualized  as  boxes  and  arrows  graphs,  and  in  DSMs,  in  parallel.  Plexus  provides  this 
capability. 

4.2  Simulation  and  Analysis 

Several  types  of  analysis  are  necessary  for  the  applications  we  have  in  mind.  These  include  traditional 
DSM  techniques  (partitioning,  cycle  identification,  dependency  tearing).  As  noted  above,  our  model 
also  includes  resources,  as  well  as  durations  for  each  activity,  and  these  can  be  augmented  with  three- 
point  probability  distributions,  constraints,  decision  points,  and  other  data.  This  data  can  be  employed 
in  discrete  event  simulations  to  optimize  scheduling,  and  to  evaluate  resource  requirements  and  the 
impacts  of  alternative  resource  scenarios,  and  to  develop  Monte  Carlo  models  of  time,  cost,  and 
resource  implications  of  uncertainty.  The  impact  of  complex  iterations  on  duration,  costs,  and  risk 
metrics  can  also  be  examined  in  these  simulations.  Deterministic  and  probabilistic  critical  path 
analysis  can  also  be  performed.  Plexus  provides  each  of  these  capabilities,  as  well  as  realistic 
rescheduling  if  resource  scenarios  or  model  details  change  during  actual  execution  of  the  model.  Being 
able  to  exploit  each  of  these  simulation  and  analysis  tools  are  a  positive  outcome  of  our  model. 


5  FINAL  COMMENTS  AND  FUTURE  GOALS 

We  feel  we  have  learned  several  important  lessons  in  building  our  model.  During  our  efforts  we  have 
worked  with  many  engineers  in  the  ship  design  community.  Responses  to  our  efforts  have  covered  the 
full  spectrum  from  strongly  positive  to  strongly  negative  and  the  range  between,  but  our  efforts  met 
with  best  success  once  we  obtained  a  collaborative,  highly  visual  boxes-and-arrows  modeling  tool  as  a 
tool  for  capturing  the  data  we  needed  for  DSM  (and  other  types)  of  analysis.  Another  key  to  our 
efforts  was  our  careful  design  of  a  regulated  vocabulary  that  was  used  in  our  modeling  workshops. 

Future  goals  of  our  efforts  include:  increasing  activity  data  definition  to  build  a  reference  library  of 
process  components,  continuing  to  validate  our  model  and  data,  exploring  simulation  and  analysis 
capabilities,  including  risk  and  uncertainty.  Finally,  we  look  forward  to  employing  the  model  in  the 
real  world  planning  and  understanding  a  ship  design. 
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